1. Field of the Invention
The present invention relates to the field of integrated circuits and, more particularly, to simulation and/or modeling systems used in the design of integrated circuits.
2. Description of the Related Art
Integrated circuits (ICs), such as field programmable gate arrays (FPGAs), can be designed using High Level Modeling Systems (HLMSs). An HLMS is a software-based design tool which provides blocks that can be combined to build a circuit design. A block refers to a high level software construct which represents a particular circuit function, such as multiplexing, addition, multiplication, or the like. The blocks can be arranged within the HLMS to form a circuit. Communication among the blocks can be represented by wires, or signals, which graphically link the blocks. Once configured, the HLMS can run various simulations upon the design. The HLMS further can generate a hardware implementation from the block representation of the circuit design. For example, an HLMS can generate the bitstream necessary to program an FPGA or can generate hardware description language (HDL) files necessary to specify the hardware design.
One example of an HLMS is System Generator™, available from Xilinx, Inc. of San Jose, Calif. System Generator™ is a system level modeling tool that facilitates FPGA hardware design. System Generator™ can function with other design tools to provide a modeling environment that is well suited to hardware design. The System Generator™ tool provides high level abstractions, i.e., blocks, which can be automatically compiled into an FPGA. In addition, access to underlying FPGA resources can be provided through low level block abstractions, which facilitate the construction of highly efficient FPGA designs.
In general, an HLMS is comprised of a plurality of different software modules. Examples of the different software modules used to form an HLMS can include, but are not limited to, connectivity handlers, various types of netlisters, simulation engines, and the like. While some of the software modules forming the HLMS may be coded in a particular, or same, programming language, it often is the case that these modules are coded using different programming languages.
One reason that software modules are coded in different programming languages is that it is desirable to incorporate modules from a variety of different manufacturers within an HLMS. It is difficult to anticipate every need of a circuit designer within a given tool. Allowing the inclusion of modules from third-party manufacturers broadens the functionality and usefulness of a tool. Each manufacturer, however, is unlikely to use a same programming language when implementing these software modules. Notwithstanding, these disparate modules must coexist and interact with one another.
Another reason for the heterogeneity among software modules of an HLMS is that software modules often are coded using a programming language that is suited to the type of data that will be processed by each module. For example, netlisting, as performed by a netlister module, refers to the process of translating a design from a high level abstraction into hardware. Netlisting usually is performed in two phases. The first involves compiling a circuit design into an intermediate format comprised of several different files. These files need not be homogeneous. For example, these intermediate files can include VHDL files, Verilog files, Xilinx NGC netlist files, cores, circuit constraints, and the like. VHDL and Verilog files are human-readable text, while Xilinx NGC files are binary. Cores can be implemented as human-readable Electronic Data Interchange Format (EDIF) files or as encrypted binary files. Circuit constraints can be specified as a Tool Command Language (Tcl) script in some cases or as Xilinx Constraint Files (XCFs) or Netlist Constraint Files (NCFs) in others.
The second phase of netlisting involves the application of standard tools, available from within a development environment such as System Generator™, to the intermediate files to generate working hardware, i.e., a bitstream for programming an FPGA. As noted, the intermediate files can be very dissimilar. Accordingly, the various tools applied to the intermediate files can be implemented in a variety of different programming languages depending upon the particular data and/or file type being processed.
Despite this heterogeneity within an HLMS, the constituent software modules must be able to exchange data between one another. Data exchange must be performed in an efficient manner as a large amount of data is exchanged within the HLMS during operation. The types of data that must be exchanged can include, but are not limited to, netlisting data, simulation data, and global session data.
Netlisting data can specify the attributes of the blocks used to construct the circuit design, data types associated with ports of the blocks, clocking and data rate information, as well as connectivity between the blocks. Simulation data specifies attributes of the blocks that affect how the block functions during simulation. This data can specify initial configurations, for example, for the blocks. Global session information specifies data that is saved when the circuit design is netlisted. This information can specify attributes such as the model name of a circuit design, various code generation options, and other data items which may be used by downstream processes.
In terms of communication within an HLMS, this data must be passed between these various modules using data types and/or structures that are supported by each programming language. Accordingly, it would be beneficial to provide a mechanism and a technique for exchanging data among software modules of an HLMS, or other heterogeneous software-based system, which overcomes the difficulties described above.